REMARKS 



This paper is in response to the Office Action mailed November 13, 2007. 



The previous Office Action rejected claims 28-36 and 40-47, as being anticipated by 
Cross. Applicants' subsequently filed Amendment amended claim 28, to its present form, to 
better define the present embodiments: 

28. (Previously Presented) Computer-implemented and Internet-based 
self-service method for a customer to dispute a pending invoice from a vendor, 
comprising the steps of: 

accessing, by the customer, a database record corresponding to the 
pending invoice to be disputed over a Web site of the vendor; 

selecting, from the vendor's Web site, a reason code for the dispute along 
with an identification of a disputed amount in the pending invoice; 

validating a Credit Memo Request incorporating the selected reason code 
and the disputed amount to create a pending Credit Memo Request; 

causing, by the customer and through the vendor's Web site, the Credit 
Memo Request to be sent to and routed through at least one of a selected process 
of the vendor for the selected reason code, a selected hierarchy of persons at the 
vendor empowered to approve Credit Memo Request incorporating the selected 
reason code and a primary approver at the vendor for the selected reason code; 

receiving a notification from the vendor upon approval or rejection of the 
pending Credit Memo Request, the disputed amount being automatically 
credited to the pending disputed invoice when the pending Credit Memo Request 
is approved. 

Similarly, independent claim 40 was amended to its present form: 

40. (Previously Presented) An Internet-based electronic self-service system 
for a customer to dispute a pending invoice from a vendor, the system 
comprising: 

a database configured to store the pending invoice; 

a Web site, the Web site being controlled by the vendor and accessible by 
the customer over the Internet, the Web site being configured to allow the 
customer to remotely access the pending invoice and to dispute the pending 
invoice by: 

selecting, from the vendor's Web site, a reason code for the dispute and at 
least a disputed amount in the pending invoice; 

validating a Credit Memo Request incorporating the selected reason code 
and the disputed amount to create a pending Credit Memo Request, and 

causing, by the customer and through the vendor's Web site, the Credit 
Memo Request to be sent to be processed through a workflow engine to send and 
route the Credit Memo Request through at least one of a selected process of the 
vendor for the selected reason code, a selected hierarchy of persons at the vendor 
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empowered to approve Credit Memo Request incorporating the selected reason 
code and a primary approver at the vendor for the selected reason code. 

Note that the claim amendments of October 24, 2007, and the arguments presented in the 

Remarks section thereof were effective to overcome the Cross reference. However, the Office now 

presents the very same arguments and rejections in paragraphs 5 and 14 relative to Cross as were 

already overcome in the Amendment filed October 24, 2007, and now asserts that the only 

difference between Cross and the claimed embodiments is that: 

However, Cross does not explicitly disclose that the dispute process is conducted 
through the vendor's Web site. 

It is respectfully submitted, however, that Cross does not teach all of the claimed methods 
but for a teaching that the dispute process is conducted through the vendor's Web site. Indeed, 
Cross teaches to upload an invoice from an external data source (see reference numeral 10 in Fig. 
1), and thereafter carry out a validation process on the received invoice "to check the actual 
charged rates against reference charged rates" (see Col. 2, lines 25-27). This validation process 
creates discrepancy information when there is a difference between charged and reference rates. In 
turn, this discrepancy information is used to generate a dispute report, which is associated with the 
received invoice (see Col. 2, lines 45-55). Once the dispute report is generated, the uploaded 
invoice may be approved or disapproved through a bill review and approval process (see Col. 2, 
lines 59-63). The invoice may be paid if approved, rejected if disapproved or short paid if only 
some of the charges therein are not approved (see also Col. 11, lines 30-50). Indeed, if the invoice 
is to be short paid (partially paid), the customer calls for the discrepancy report to be sent to the 
vendor, the party that generated the bill. 

Therefore, as set out previously, Cross teaches to: 
1 . upload a vendor bill; 

3 

OID-1999-180-01 Serial No. 10/759,318 

Atty. Docket No. ORCL5643DIV 



2. carry out a validation process on the uploaded bill; 

3. generate discrepancy information and a dispute report according to the results of the 
validation process if the charged rates do not match reference rates, and 

4. carry out one of three steps; namely: 

a. approve and pay the invoice (see Col. 1 1 , lines 34-35) 

b. reject the invoice and mark the invoice as rejected (see Col. 11, lines 40-41), or 

c. short pay the invoice and send a dispute report to the vendor (see Col. 22, lines 36-38). 

No teaching or suggestion is present in Cross of any customer carrying out a self-service 
method of disputing a pending invoice by creating a Credit Memo Request as called for by claim 1 . 
In Cross, the uploaded invoice is paid, rejected, or partially paid, and no request for any Credit 
Memo is ever made to the vendor (the entity that generated the invoice). In fact, as noted in the 
previously filed Amendment, Cross teaches that the customer is in contact with the vendor on only 
three occasions : 

1 . One connection is made to the external data source 10 to access and upload the invoice 
(see Col. 4, lines 59-60); 

2. One connection is made through the autopayment interface 13 when the invoice is paid 
(see Col. 5, lines 1-10), and 

3. One last connection is made through an invoice and dispute report output to provide 
copies of invoices and dispute reports to the vendor. 

All of the other steps and processes described in Cross are carried out internally within the 

customer. That is, the customer does not carry out a step of: 

accessing, by the customer, a database record corresponding to the 
pending invoice to be disputed over a Web site of the vendor 

Nor does the customer carry out, as claimed, a step of: 

selecting, from the vendor's Web site, a reason code for the dispute along 
with an identification of a disputed amount in the pending invoice 

The Reason Codes in Cross (see, for example, Fig. 8) are the customer's internal reason codes, and 

are not vendor-provided, as they are in the claimed embodiments. Indeed, Cross teaches to 
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approve, disapprove or short pay an invoice internally, within itself, and does not teach or suggest 

any manner of generating a Credit Memo Request at all, and much less by: 

causing, by the customer and through the vendor's Web site, the Credit 
Memo Request to be sent to and routed through at least one of a selected process 
of the vendor for the selected reason code, a selected hierarchy of persons at the 
vendor empowered to approve Credit Memo Request incorporating the selected 
reason code and a primary approver at the vendor for the selected reason code 

As successfully pointed out previously, the pending claims recite that the Credit Memo 

Request is created through the vendor's Web site and by the customer , which is antithetical to the 

method espoused by Cross, in which the customer (invoice recipient) does not: i) access the 

vendor's Web site; ii) generate a Request for a Credit Memo; or iii) cause any Credit Memo 

Request to be sent and routed to the vendor in the claimed (or any) manner. 

It is respectfully submitted to the Examiner that the discrepancy information and the 
dispute report taught by Cross is not equivalent to the claimed Credit Memo Request, nor are the 
claimed steps to create the claimed Credit Memo Request taught in Cross; whether carried out 
through the vendor's Web site or not. In Cross, the dispute report is generated within the customer, 
without any contact with the vendor, and merely sent to the vendor when the customer short pays 
the vendor (see Col. 11, lines 36-39). The dispute report is not created through the vendor's web 
site, as required by the claims. Nor is it caused to be routed through "at least one of a selected 
process of the vendor for the selected reason code, a selected hierarchy of persons at the vendor 
empowered to approve Credit Memo Request incorporating the selected reason code and a primary 
approver at the vendor for the selected reason code," as required by the claims. 

Therefore, it is respectfully submitted that the primary reference of the applied combination 
does not teach or suggest that which is again asserted by the Office. In the outstanding Office 
Action, the Office has changed the anticipation rejection to an obviousness rejection and added the 
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secondary reference to Robinson et al. for its alleged teaching of the dispute process being 
"conducted thru the vendor's Web site." 



Before considering the two references ion combination for all they teach and suggest to one 
of ordinary skill, as one must in the context of a § 103(a) rejection, an examination of the Robinson 
et al. patent is instructive. 



Robinson et al. teach methods and systems for creating an encrypted digital receipt (see, for 
example, the title and the Abstract of Robinson et al). The focus of Robinson et al. is to provide 
private records of an online transaction that may be trusted by both parties (see Col. 2, lines 7-13): 

Of course the customer could also create and retain their 
own records, but the merchant may not trust the customer's 
records since, being in digital form, they are easily modified 
0 or forged. Thus, disputes arising from electronic transactions 
over the Internet are typically difficult to resolve since 
neither the merchant nor the customer trusts the accuracy of 
the other's private records. 

To provide "private records" that may be trusted by both the merchant and the customer, 
Robinson et al. teaches the generation of encrypted receipts for online transactions. To do so, 
Robinson et al. teach to generate a transaction record that contains "at least some information that, 
on its face, would identify the transaction to the merchant (see Col. 4, lines 45-47). This transaction 
record is then encrypted (see Col. 5, lines 12-17): 

In step 115, the transaction record is encrypted. Note that 
the encryption of step 115 is used primarily for the purpose 
of verification by the merchant. For example, the merchant 
may need to verify the transaction record in the event of 15 
disputes with the customer or in the case when its own 
transaction record is lost. Thus, if a private-key cryptosys- 

This encrypted "digital receipt" (Robinson et al.'s terminology) is then transmitted back to 
the customer (see Col. 6, lines 23-25): 

Referring again to FIG. 1, in step 120 the encrypted 
transaction record, which ordinarily is appended to the 
2S digital receipt page, is transmitted back to the customer. 
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The customer then saves this encrypted digital receipt (see Col. 6, lines 48-50), who may 



then use the encrypted digital receipt "in case of disputes or problems with the order," as taught in 
Robinson et al. (see Col. 6, lines 61-64): 

Using a digital receipt in accordance with the invention, the 
merchant may issue a digital receipt to a customer, and 
advise its customers to save the digital receipt in case of 
disputes or problems with the order. By using digital 

The customer, it is disclosed (see at Col. 8, lines 31-35) "may wish to present" the digital 
receipt to the merchant when there is a dispute or whenever the customer or the merchant wishes to 
verify that a particular transaction took place or to verify that the customer is entitled to discounts: 

tication of the transaction. The customer may wish to present 
the digital receipt to the merchant in the event of a dispute 
with the merchant, but in general the customer may do so 
whenever he wishes to verily that a particular transaction 
, 5 took place. For example, a customer may present digital 
receipts to the merchant to verify that he is entitled to certain 
volume-based discounts. 



Robinson et al.'s encrypted digital receipt, therefore, is a proof-of-purchase certificate that 
may be trusted by the merchant and relied upon by the customer. Indeed, the digital receipt 
provides some assurances to both the merchant and the customer (see Col. 9, lines 13-26): 

In this way, according to the invention, the merchant is 
able to verify a digital receipt presented by a customer. The ^ 
merchant advantageously is able to trust that a particular 
transaction took place, and further, that particular informa- 
tion such as price, quantity, and exact time of transaction are 
accurately reflected on the confirmation message. A valuable 
result of the relatively high level of trust afforded to the 
merchant by the present invention is that the merchant 
thereby is able to guarantee to the customer that the digital 
receipt issued to the customer will be honored as proof of the 
transaction. Thus, in addition to the benefits to the merchant, 
the present invention provides an unexpected benefit to the ^ 
customer in that it allows merchants to guarantee issued 
digital receipts. 

Nowhere, however, do Robinson et al. teach or suggest, "the dispute process is 
conducted thru the vendor's Web site" as asserted by the Office on page 4 of the outstanding 
Office Action. Robinson et al. teaches a trusted digital receipt that may be used as a trusted 
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record of a past online transaction in cases in which a dispute arises. Robinson et al. are 
entirely silent as to any steps of: i) selecting, from the vendor's Web site, a reason code for the 
dispute along with an identification of a disputed amount in the pending invoice; ii) validating 
a Credit Memo Request, incorporating the selected reason code and the disputed amount to 
create a pending Credit Memo Request; iii) causing, by the customer and through the vendor's 
Web site, the Credit Memo Request to be sent and routed through at least one of a selected 
process of the vendor for the selected reason code, a selected hierarchy of persons at the vendor 
empowered to approve Credit Memo Request, incorporating the selected reason code and a 
primary approver at the vendor for the selected reason code; and iv) receiving a notification 
from the vendor upon approval or rejection of the pending Credit Memo Request, the disputed 
amount being automatically credited to the pending disputed invoice when the pending Credit 
Memo Request is approved, as claimed herein. 

Simply put, Robinson et al. are entirely silent as to how a customer dispute is 
processed, other than their repeated teachings that their encrypted digital receipt should be 
saved by the customer so that he or she may present the saved digital receipt to the merchant in 
case a dispute arises. That is it, in Robinson et al., relative to the procedure for processing 
customer-initiated disputes: the customer is to present his or her saved encrypted digital receipt 
as a proof-of-purchase that may be trusted by the merchant and relied upon by the customer. 

Considering now the Cross and Robinson et al. references in combination , as in proper 
in the context of a § 103(a) rejection, the undersigned notes the following. 

The combination appears to teach, as set out in Cross, to: 
1) upload a vendor bill; 
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2) carry out a validation process on the uploaded bill; 

3) generate discrepancy information and a dispute report according to the results of the 
validation process if the charged rates do not match reference rates, and 

4) carry out one of three steps; namely: 

a. approve and pay the invoice (see Cross, Col. 1 1 , lines 34-35) 

b. reject the invoice and mark the invoice as rejected (see Cross, Col. 11, lines 40- 
41), or 

c. short pay the invoice and send a dispute report to the vendor (see Cross, Col. 
22, lines 36-38). 

The encrypted digital receipt of Robinson et al., within the framework of Cross, would only 
be useful when the customer short pays the vendor's invoice and sends a dispute report to the 
vendor, as in 3) immediately above. Indeed, according to the applied combination of references, 
the customer could then provide the saved encrypted digital invoice back to the vendor (as the 
merchant is called in Cross), as proof that the customer purchased the goods or services identified 
in the short-paid invoice, as taught by Robinson et al. 

Kindly recall that no teaching or suggestion is present in the primary reference to Cross of 
any customer carrying out a self-service method of disputing a pending invoice by creating any 
manner of Credit Memo Request as called for by claims 28 or 40. In Cross, the uploaded invoice is 
paid, rejected, or partially paid, and no request for any Credit Memo is ever made to the vendor 
(the entity that generated the invoice). In fact, Cross teaches that the customer is in contact with the 
vendor on only three occasions : 

1) One connection is made to the external data source 10 to access and upload the invoice 
(see Col. 4, lines 59-60); 

2) One connection is made through the autopayment interface 13 when the invoice is paid 
(see Col. 5, lines 1-10), and 

3) One last connection is made through an invoice and dispute report output to provide 
copies of invoices and dispute reports to the vendor. 
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It is only at 3) that it makes sense for the customer of Cross to use Robinson et al.'s 
encrypted digital receipt, and only for the purpose of verifying, to the satisfaction of the vendor, 
that the customer purchased the goods or services listed on the short paid invoice in question. 

The applied combination, it is respectfully submitted, does not teach or suggest the claimed 
subject matter. Indeed, the applied combination does not teach or suggest creating a Credit Memo 
Request or any of the steps of claim 28, of: 

causing, by the customer and through the vendor's Web site, the Credit 
Memo Request to be sent to and routed through at least one of a selected process 
of the vendor for the selected reason code, a selected hierarchy of persons at the 
vendor empowered to approve Credit Memo Request incorporating the selected 
reason code and a primary approver at the vendor for the selected reason code; 

receiving a notification from the vendor upon approval or rejection of the 
pending Credit Memo Request, the disputed amount being automatically 
credited to the pending disputed invoice when the pending Credit Memo Request 
is approved. 

The applied combination also does not teach or suggest the step of claim 40: 

causing, by the customer and through the vendor's Web site, the Credit 
Memo Request to be sent to be processed through a workflow engine to send and 
route the Credit Memo Request through at least one of a selected process of the 
vendor for the selected reason code, a selected hierarchy of persons at the vendor 
empowered to approve Credit Memo Request incorporating the selected reason 
code and a primary approver at the vendor for the selected reason code. 

For the foregoing reasons, therefore, it is respectfully requested that the 35 U.S.C. § 103(a) 

rejections applied to the claims be reconsidered and withdrawn. 
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Applicants believe that this application is now in condition for allowance. If any unresolved 
issues remain, please contact the undersigned attorney of record at the telephone number indicated 
below and whatever is necessary to resolve such issues will be done at once. 



YOUNG LAW FIRM, P.C. 
4370 Alpine Rd., Ste. 106 
Portola Valley, CA 94028 
Tel.: (650) 851-7210 
Fax: (650) 851-7232 



C:\YLF\CLIENTS\ORCL\5643\DIV\5643DIV AMEND3.doc 



Respectfully submitted, 



Date:. 



March 13. 2008 



By:. 




Alan W. Young 
Attorney for Applicants 
Registration No. 37,970 
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